Rather than do nothing, assume the user knows what they are doing and
re-use the environment the language server itself is written in.

This makes the server's initializationOptions the lowest priority
setting, allowing for them to be used as fallback options specified by
the client

This commit removes the following options

- ``esbonio.sphinx.envPassthrough``: For ages now, the language server
  passes through all environment variables to the sphinx process so
  this option has no use.

- ``esbonio.sphinx.pythonPath``: I think the original intent behind
  this option was to allow you to override the version of the sphinx
  agent.

  However, the better way to do this is just use a different version
  of ``esbonio``.

- ``esbonio.sphinx.cwd``: Use ``esbonio.sphinx.pythonCommand.cwd``.

- ``esbonio.sphinx.fallbackEnv``: This was a hack to allow the VSCode
  extension to provide a default environment in the absence of any
  user configuration.

  From now on, clients should set ``esbonio.sphinx.pythonCommand`` in
  the initializationOptions they send.

This commit also converts ``esbonio.sphinx.pythonCommand`` from a
simple list to an object in its own right.

  - ``esbonio.sphinx.pythonCommand.command``: This list of strings
    from the original ``esbonio.sphinx.pythonCommand.``

  - ``esbonio.sphinx.pythonCommand.env``: A dictionary allowing you to
    add/override environment variables passed to the sphinx process.

  - ``esbonio.sphinx.pythonCommand.cwd``: A string allowing you to
    change the directory in which the sphinx process is launched.

Now 95% of the time, the simple list of strings was sufficient so if
the server is given a list of strings for
``esbonio.sphinx.pythonCommand`` it will be automatically converted to
the object representation.

This batch of changes has unearthed a bunch of interesting timing issues
during server start up.

I was seeing an issue where the `esbonio.sphinx.pythonCommand`
configuration was not being applied *only* in the case where I had one
or more `*.rst` files open before restarting the server.

I eventually realised that this was due to the `textDocument/didOpen`
notification handlers winning the race with the `initialized`
notification handler and creating a `SphinxConfig` configuration
subscription **before** the additional structure hooks in the
`SphinxManager` could be registered.

This meant the promotion of `list[str]` values to `SubProcess` values
was not happening for these early subscriptions.

More broadly, this probably points to a need to reconsider the startup
sequence at some point, but running this code during `initialize`
(during which time other messages are forbidden) should be enough to
paper over the issue for now.

Related to the previous commit, the server was declaring itself ready
before all the `initialized` handlers of the features were processed.

This commit therefore attempts to be more correct by delaying the
resolution of the `ready` future until after the execution of these
handlers. However, the previous commit also demonstrates how this
already insufficient to ensure correct behaviour as other
requests/notifications are free to be serviced concurrently with
`initialized`.

The "obvious" fix for this would be to move all setup code into the
`initialize` handler, but there is at least one situation where this
cannot be done and that is the configuration system. Initializing the
configuration system involves making `workspace/configuration` requests
to the client - which are forbidden until after the `initialize` result
has been sent!

As I write this, perhaps the other "obvious" solution is to have all of
the message handlers in `esbonio/server/setup.py` consult the state of
the `ready` future before proceeding... but for some reason (I can't quite
articulate why) that doesn't feel like an ideal solution...

Originally I'd set this up to use ruff via `hatch fmt` but it's
awkward to integrate with pre-commit and ensure that everything uses a
consistent config.

Eventually, we should be able to simplify that ruff config a bit!

Bumps the actions group with 4 updates: [actions/checkout](https://github.com/actions/checkout), [actions/setup-python](https://github.com/actions/setup-python), [actions/setup-node](https://github.com/actions/setup-node) and [actions/download-artifact](https://github.com/actions/download-artifact).


Updates `actions/checkout` from 4 to 5
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v4...v5)

Updates `actions/setup-python` from 5 to 6
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](actions/setup-python@v5...v6)

Updates `actions/setup-node` from 4 to 5
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](actions/setup-node@v4...v5)

Updates `actions/download-artifact` from 4 to 5
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](actions/download-artifact@v4...v5)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: actions
- dependency-name: actions/setup-python
  dependency-version: '6'
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: actions
- dependency-name: actions/setup-node
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: actions
- dependency-name: actions/download-artifact
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: actions
...

Signed-off-by: dependabot[bot] <[email protected]>

I deleted the `ln` command recently as the link was already present in
CI. Yet now that I run it locally, the link is not being automatically
created?

Hopefully, this will allow the command to work in either scenario

If dependencies have already been installed into `node_modules/`
assume we've bumped dependencies and want a refresh of the locks.

Otherwise assume we want the dependencies to be reproduced as-is

Bumps the vscode-ext group with 1 update in the /code directory: [@vscode/vsce](https://github.com/Microsoft/vsce).


Updates `@vscode/vsce` from 3.6.0 to 3.6.2
- [Release notes](https://github.com/Microsoft/vsce/releases)
- [Commits](microsoft/vscode-vsce@v3.6.0...v3.6.2)

---
updated-dependencies:
- dependency-name: "@vscode/vsce"
  dependency-version: 3.6.2
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: vscode-ext
...

Signed-off-by: dependabot[bot] <[email protected]>

updates:
- [github.com/pre-commit/pre-commit-hooks: v5.0.0 → v6.0.0](pre-commit/pre-commit-hooks@v5.0.0...v6.0.0)
- [github.com/astral-sh/ruff-pre-commit: v0.13.1 → v0.13.3](astral-sh/ruff-pre-commit@v0.13.1...v0.13.3)
- [github.com/pre-commit/mirrors-mypy: v1.16.1 → v1.18.2](pre-commit/mirrors-mypy@v1.16.1...v1.18.2)

Bumps the vscode-ext group in /code with 2 updates: [ovsx](https://github.com/eclipse/openvsx/tree/HEAD/cli) and [typescript](https://github.com/microsoft/TypeScript).


Updates `ovsx` from 0.10.5 to 0.10.6
- [Release notes](https://github.com/eclipse/openvsx/releases)
- [Changelog](https://github.com/eclipse/openvsx/blob/master/cli/CHANGELOG.md)
- [Commits](https://github.com/eclipse/openvsx/commits/HEAD/cli)

Updates `typescript` from 5.9.2 to 5.9.3
- [Release notes](https://github.com/microsoft/TypeScript/releases)
- [Changelog](https://github.com/microsoft/TypeScript/blob/main/azure-pipelines.release-publish.yml)
- [Commits](microsoft/TypeScript@v5.9.2...v5.9.3)

---
updated-dependencies:
- dependency-name: ovsx
  dependency-version: 0.10.6
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: vscode-ext
- dependency-name: typescript
  dependency-version: 5.9.3
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: vscode-ext
...

Signed-off-by: dependabot[bot] <[email protected]>